Sorry for the letting the ball drop on this for a while. I'm gonna begin to address the reviews. To start:

• I renamed the method to eth_multicall
• Changed it so you provide one set of block overrides, instead of per call

Will address the rest of reviews on their respective comments.

I think there would be value in making it so eth_multicall can provide multiple "blocks" of transactions that each have their own set of overrides. This would allow someone to have a multicall that sets some state, then waits some amount of time, then executes something which is incredibly valuable for testing things like timelocks and whatnot.

My initial thinking is to have something like:

{
	parent_block,
	blocks: [
		{ block_overrides, transactions },
		{ block_overrides, transactions },
		...
	]
}

Everything else would stay the same, and the first block in the array would be built on top of the looked up parent_block, then the second block in the array would be built on top of the first block, etc. Each block could then have its gas limit constrained by normal validation rules but this would allow unlimited total gas spent across all execution and allow testing things that are a function of time.

Also it's worth discussing a deprecation policy for API methods. Multicall is more general than call and if adopted will fully supersede eth_call.

I think multiblock/chain execution is a useful feature. However after reading comments such as ethereum/go-ethereum#25743 (comment) and thinking more about this, I've made up my mind and would like to champion only the single-block-multi-call variant at this time.

How I envision the multiBlockCall method right now is taking a list of something akin to a full block object (similar to how txes are passed to eth_call). That is a detriment in UX for users who want to do a simple multicall IMO.

I believe the referenced comment by @holiman is indicating that having multiple transactions with different block parameters could have sharp edges. A multi-block multicall however wouldn't have such sharp edges.

That is a detriment in UX for users who want to do a simple multicall IMO.

Wouldn't the difference between single block and multiblock (for a multicall that only actually spans one block) just be a couple extra sets of braces and a property name more or less? If we use a tuple you don't even need the property name (though I don't recommend that).

{ block, stateOverrides, blockOverrides, calls: [transaction1, transaction2, ..., transactionN }

vs

{ block, blocks: [ { stateOverrides, blockOverrides, calls: [transaction1, transaction2, ..., transactionN } ] }

It would be unfortunate to need a separate JSON-RPC method for multiblock call when the difference between them is so minimal, and the work required to implement them both is likely very similar, especially since single block multicall is purely a subset of multi block multicall.

A multi-block multicall however wouldn't have such sharp edges.

I'm pretty sure his later comment applies to multi-block. There is a difference between simply executing multiple txes and executing txes from different blocks (doesn't matter if they are ordered blocks). Namely, it is the coinbase reward at the moment. Soon it will also include the withdrawal logic. Also once you have multiple blocks you need to get BLOCKHASH opcode right.

just be a couple extra sets of braces and a property name more or less?

No because once you have multiple blocks the override fields become mandatory. Unless you special-case it for one block, but that's ugly IMO.

No because once you have multiple blocks the override fields become mandatory. Unless you special-case it for one block, but that's ugly IMO.

Why would you require block overrides for multiple blocks but not for single block? It seems to me that you either need to require overrides in both cases, or they are optional in both cases. Can you elaborate on why you think these situations are different?

I'm pretty sure his later comment applies to multi-block. There is a difference between simply executing multiple txes and executing txes from different blocks (doesn't matter if they are ordered blocks). Namely, it is the coinbase reward at the moment. Soon it will also include the withdrawal logic. Also once you have multiple blocks you need to get BLOCKHASH opcode right.

It is certainly possible that there are some implementation detail in some client that make building multiple blocks in a row outside of current chain particularly difficult, but that feels unlikely to me (would be great to get a concrete answer from client devs on this). In Nethermind at least, I believe it would not be notably harder to build a two-block chain in memory vs a one-block chain in memory.

Can this be named something other than multicall as that is confusing , maybe eth_macroCall ?

@MicahZoltu are you willing to champion the multi-block variant as a separate proposal? we can raise them both during ACD as alternatives. I'd be happy if either of them gets adopted and can take care of the implementation in Geth.

I'm all for the extra flexibility of the multi-block variant, but it seems to me that the use-case is more niche and I don't want the extra complexity to delay adoption.

Why would you require block overrides for multiple blocks but not for single block? It seems to me that you either need to require overrides in both cases, or they are optional in both cases. Can you elaborate on why you think these situations are different?

For a single block you can simply take the parameters of block (which we take the state from) as default. Once you have multiple blocks either we can use the same default for all blocks (possibly incrementing NUMBER) or make the overrides mandatory.

Can this be named something other than multicall as that is confusing , maybe eth_macroCall ?

@sambacha I would go with eth_swissArmyCall for the multi-block variant hehe.

Can this be named something other than multicall as that is confusing , maybe eth_macroCall ?

What do you find confusing about multicall?

I'm all for the extra flexibility of the multi-block variant, but it seems to me that the use-case is more niche and I don't want the extra complexity to delay adoption.

Given how difficult it is to get new JSON-RPC methods standardized, I think that we should take our time and spec this out in a way that we think is best long term for the ecosystem, rather than trying to do the thing that requires the least amount of work. I say this as someone who is currently working on a project that has a hard dependency on the single-block version of this too, and I don't benefit directly at all from the multi-block version!

For a single block you can simply take the parameters of block (which we take the state from) as default. Once you have multiple blocks either we can use the same default for all blocks (possibly incrementing NUMBER) or make the overrides mandatory.

I agree with this, but it doesn't seem to answer my question of why multi-block requires overrides? Am I misunderstanding something, because it sounds like you are saying that multiblock does not require overrides?

Note: Each successive block should increment the time by 12 seconds and the block number by 1 by default. This includes the first block built on the real chain, and the subsequent blocks. They should keep the gas limit unchanged from the parent, and probably just include a a deterministic "random" number for randao (which IIRC is now in the block header) like hash the parent's randao or something. This should be written into the standard (regardless of whether we do multi-block or single-block).

are you willing to champion the multi-block variant as a separate proposal? we can raise them both during ACD as alternatives. I'd be happy if either of them gets adopted and can take care of the implementation in Geth.

I would much rather go to ACD with a single proposal than two competing proposals. We have seen in the past how two competing proposals both being championed can indefinitely delay inclusion (e.g., BLS), so generally speaking it is best to get agreement among champions first.

That being said, perhaps we could go to ACD with the multiblock proposal but mention that if any of the clients believe multiblock will be particularly difficult to implement then that is something that can be pulled out of the proposal? As I mentioned above, my suspicion is that they are nearly equally difficult to implement but if one or more client teams indicate that their architecture makes multiblock hard that is the most likely thing to convince me to back off.

I want to test this extension on my geth but, how do I call the JSON-RPC I couldn't figure. Can you give an example please?

I would like to see a standardized batch call method implemented into geth upstream and of the available proposals, this one seems like the best and even has an implementation with an open PR (ethereum/go-ethereum#25743) that is only blocked by the spec agreement.

There have also been attempts to put eth_callBundle (Flashbots-specific non-standard API I helped create) but i would like to see something more flexible and useful across multiple blocks with features for security researchers and end users (wallets) as well. If eth_batchCall (or similar) is upstreamed into geth, i think Flashbots is likely to switch to it and recommend its use in their libraries and documentation.

I woud like to see this API used to prevent Ethereum users from being scammed by tokens that only allow purchase (and revert on sell). An API like this could verify the ability to re-sell tokens and automatically protect users.

@s1na i see there was some correspondence here but that after a few comments, momentum was lost, are you open to continuing this discussion and helping get this across the line? I would be happy to jump on a call to hash things out or add more resources as necessary, i think this is important work and not too far from being completed.